Extracting and processing metrics from system generated events

ABSTRACT

In an example, a processing system of a database system may categorize event data taken from logged interactions of users with a multi-tenant information system to provide a metric. The processing system of the database system may periodically calculate the metric for a particular one of the tenants, and electronically store the periodically calculated metrics for accessing responsive to a query of the particular tenant.

CLAIM OF PRIORITY

This application claims the benefit of U.S. Provisional PatentApplication 62/048,961 entitled Extracting and Processing Metrics fromSystem Generated Events, by Aakash Pradeep et al., filed Sep. 11, 2014,the entire contents of which are incorporated herein by reference.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent file or records, but otherwise reserves all copyrightrights whatsoever.

CROSS REFERENCE TO RELATED APPLICATIONS

The following commonly owned, co-pending non-provisional United StatesPatents and Patent Applications, including the present application, maybe related to each other. Each of the other patents/applications areincorporated by reference herein in its entirety:

U.S. patent application Ser. No. 14/688,917 entitled EXTRACTION ANDCAPTURE OF INFORMATION FROM CUSTOMIZABLE HEADER, filed Apr. 16, 2015.

FIELD OF THE INVENTION

One or more implementations relate generally to extracting andprocessing metrics from system generated events in a database networksystem environment.

BACKGROUND

The subject matter discussed in the background section should not beassumed to be prior art merely as a result of its mention in thebackground section. Similarly, a problem mentioned in the backgroundsection or associated with the subject matter of the background sectionshould not be assumed to have been previously recognized in the priorart. The subject matter in the background section merely representsdifferent approaches, which in and of themselves may also be inventions.

Many multi-tenant database system today produce system generated eventssuch as logins, downloads, transactions, or anything that can beconstrued as an application event associated with a specific customerinstance. These systems provide for various forms of electroniccommunication between customers and host system.

It has become common practice for institutions to extract electroniccommunication information from these systems. Given the affordability ofdata storage and the potential necessity of such information, manyinstitutions retain electronic copies of information. For example, inindustries such as financial and legal services as well as many others,it is often important to maintain a “paper trail”. Information such aswhat information is being accessed by whom, and when it is beingaccessed may be required for audits or investigations. In certain cases,electronic records may even be subpoenaed, and file storage devices thatstore such information may be subject to computer forensic searches.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following drawings like reference numbers are used to refer tolike elements. Although the following figures depict various examples,the one or more implementations are not limited to the examples depictedin the figures.

The included drawings are for illustrative purposes and serve to provideexamples of possible structures and operations for the disclosedinventive systems, apparatus, methods and computer-readable storagemedia. These drawings in no way limit any changes in form and detailthat may be made by one skilled in the art without departing from thespirit and scope of the disclosed implementations.

FIG. 1A shows a block diagram of an example environment in which anon-demand database service can be used according to someimplementations.

FIG. 1B shows a block diagram of example implementations of elements ofFIG. 1A and example interconnections between these elements according tosome implementations.

FIG. 2A shows a system diagram of example architectural components of anon-demand database service environment according to someimplementations.

FIG. 2B shows a system diagram further illustrating examplearchitectural components of an on-demand database service environmentaccording to some implementations.

FIG. 3 is an operational flow diagram illustrating a process that may beperformed by a processing system of a database system for extracting andprocessing metrics from system generated events.

FIG. 4A is an example of code to define a metric.

FIG. 4B is an example of raw event data.

FIG. 4C is an example of a graphical user interface to query a platformevent metric object.

FIG. 4D is an example of viewing a result of the query to the platformevent metric object using a visualization tool.

DETAILED DESCRIPTION

Examples of systems, apparatus, computer-readable storage media, andmethods according to the disclosed implementations are described in thissection. These examples are being provided solely to add context and aidin the understanding of the disclosed implementations. It will thus beapparent to one skilled in the art that the disclosed implementationsmay be practiced without some or all of the specific details provided.In other instances, certain process or method operations, also referredto herein as “blocks,” have not been described in detail in order toavoid unnecessarily obscuring the disclosed implementations. Otherimplementations and applications also are possible, and as such, thefollowing examples should not be taken as definitive or limiting eitherin scope or setting.

In the following detailed description, references are made to theaccompanying drawings, which form a part of the description and in whichare shown, by way of illustration, specific implementations. Althoughthese disclosed implementations are described in sufficient detail toenable one skilled in the art to practice the implementations, it is tobe understood that these examples are not limiting, such that otherimplementations may be used and changes may be made to the disclosedimplementations without departing from their spirit and scope. Forexample, the blocks of the methods shown and described herein are notnecessarily performed in the order indicated in some otherimplementations. Additionally, in some other implementations, thedisclosed methods may include more or fewer blocks than are described.As another example, some blocks described herein as separate blocks maybe combined in some other implementations. Conversely, what may bedescribed herein as a single block may be implemented in multiple blocksin some other implementations. Additionally, the conjunction “or” isintended herein in the inclusive sense where appropriate unlessotherwise indicated; that is, the phrase “A, B or C” is intended toinclude the possibilities of “A,” “B,” “C,” “A and B,” “B and C,” “A andC” and “A, B and C.”

Some implementations described and referenced herein are directed tosystems, apparatus, computer-implemented methods and computer-readablestorage media for extracting and processing metrics from systemgenerated events.

In some implementations, a processing system of a database system isprovided. The processing system may extract and store certain contentfrom users interacting with a multi-tenant database system. Theprocessing system may also determine a profile as well as anauthenticity of customer users accessing information of the multi-tenantdatabase system. The processing system may also process extractedmetrics to determine a profile of the user accessing the information.The profile may be used, for example, to determine whether a particularaccess by a purported user may be an access by a different user, basedon the profile of the purported user.

In some embodiments, the information generated for each customerinstance is captured passively. That is, the information is capturedwithout any interruption to the user. The information may also be storedon a database and examined at a later time by an administrator. Forexample, a generic Application Program Interface (API) may capture theinformation and store it on a distributed database, such as anon-relational, distributed database. In some instances, the informationmay be retrieved from the database and processed. This processing of theinformation may help product a “fingerprint” that identifies and/orauthenticates a user. In some implementations, for each user instance,information such as user identification, time stamp, browser used,version of the browser, IP address, referring URL and an assortment ofother information may be collected and stored. Once collected, theprocessing system may categorize the information to produce a variety ofmetrics. A metric may be used individually or in combination withanother metric in a requested query by, or for, a tenant.

In some embodiments, the processing system may identify an aggregatefunction on an event attribute for a duration. The processing system mayidentify a threshold according to available aggregation functionresults. The processing system may compare a new aggregate functionresult to the identified threshold. The processing system may transmitan alert responsive to a result of the comparison.

In some embodiments, one example metric for categorization may be thenumber of instances of logins per user. The instances of logins may beprocessed to determine an average number of login events. After anaverage has been determined, a graph may be produced where outliers maybe easily determined based on the graphical depiction of the results. Insome cases, excessive number of login events may suggest a securitybreach. That is, if the average number of logins per day for a user isfive, and one user is determined to have logged in 15 times, anindication of a potential security breach may be suggested since thereare not many instances where that many additional logins are necessary.In some embodiments the processing system may provide an alert in suchan instance, where the number of logins exceeds a predeterminedthreshold amount based on an average number of logins.

Another example metric for categorization may be the hours when a useris logged in. In general, one can expect users to be logged in duringwork hours, typically between 9 am and 5 pm, or thereabouts. Anyinstances of outliers, again, may suggest a security breach thattriggers an alert. However, work hours may vary from user to user. Thus,while a common trend may exist among most users, this common trend maynot be representative of all users. Accordingly, it may be helpful todetermine not only a trend among a set of users, but the trend of asingle user over a period of time, since a single user's daily activitymay be inconsistent from a group of users with which the single user isassociated.

Another example metric for categorization may be the location of a userby way of IP addresses. Since IP addresses provide an indication of thelocation of a user, analyzing and graphing a user based on IP addressranges may provide an indication of the authenticity of each instance ofthe user login. For example, when a user is determine to have logged infrom an IP address associated with a first location, and then logs in ashort time later from an IP address associated with a second locationthat is far removed from the first location, it is likely that the loginwas performed by two different people using a same account, thussuggesting a security breach. Similarly, the use of two different typesof browsers over a short period of time may also suggest different userslogging into the same account. Typically, users have the habit of usingthe same browser on a personal home or work computer. Thus, a change inthe type of browser, e.g. brand, or the version of the browser maysuggest multiple users. Both instances may trigger an alert beingprovided.

In some implementations, the users described herein are users (or“members”) of an interactive online “enterprise social network,” alsoreferred to herein as an “enterprise social networking system,” an“enterprise collaborative network,” or more simply as an “enterprisenetwork.” Such online enterprise networks are increasingly becoming acommon way to facilitate communication among people, any of whom can berecognized as enterprise users. One example of an online enterprisesocial network is Chatter®, provided by salesforce.com, inc. of SanFrancisco, Calif. salesforce.com, inc. is a provider of enterprisesocial networking services, customer relationship management (CRM)services and other database management services, any of which can beaccessed and used in conjunction with the techniques disclosed herein insome implementations. These various services can be provided in a cloudcomputing environment as described herein, for example, in the contextof a multi-tenant database system. Some of the described techniques orprocesses can be implemented without having to install software locally,that is, on computing devices of users interacting with servicesavailable through the cloud. While the disclosed implementations may bedescribed with reference to Chatter® and more generally to enterprisesocial networking, those of ordinary skill in the art should understandthat the disclosed techniques are neither limited to Chatter® nor to anyother services and systems provided by salesforce.com, inc. and can beimplemented in the context of various other database systems such ascloud-based systems that are not part of a multi-tenant database systemor which do not provide enterprise social networking services.

I. Example System Overview

FIG. 1A shows a block diagram of an example of an environment 10 inwhich an on-demand database service can be used in accordance with someimplementations. The environment 10 includes user systems 12, a network14, a database system 16 (also referred to herein as a “cloud-basedsystem”), a processor system 17, an application platform 18, a networkinterface 20, tenant database 22 for storing tenant data 23, systemdatabase 24 for storing system data 25, program code 26 for implementingvarious functions of the system 16, and process space 28 for executingdatabase system processes and tenant-specific processes, such as runningapplications as part of an application hosting service. In some otherimplementations, environment 10 may not have all of these components orsystems, or may have other components or systems instead of, or inaddition to, those listed above.

In some implementations, the environment 10 is an environment in whichan on-demand database service exists. An on-demand database service,such as that which can be implemented using the system 16, is a servicethat is made available to users outside of the enterprise(s) that own,maintain or provide access to the system 16. As described above, suchusers generally do not need to be concerned with building or maintainingthe system 16. Instead, resources provided by the system 16 may beavailable for such users' use when the users need services provided bythe system 16; that is, on the demand of the users. Some on-demanddatabase services can store information from one or more tenants intotables of a common database image to form a multi-tenant database system(MTS). The term “multi-tenant database system” can refer to thosesystems in which various elements of hardware and software of a databasesystem may be shared by one or more customers or tenants. For example, agiven application server may simultaneously process requests for a greatnumber of customers, and a given database table may store rows of datasuch as feed items for a potentially much greater number of customers. Adatabase image can include one or more database objects. A relationaldatabase management system (RDBMS) or the equivalent can execute storageand retrieval of information against the database object(s).

Application platform 18 can be a framework that allows the applicationsof system 16 to execute, such as the hardware or software infrastructureof the system 16. In some implementations, the application platform 18enables the creation, management and execution of one or moreapplications developed by the provider of the on-demand databaseservice, users accessing the on-demand database service via user systems12, or third party application developers accessing the on-demanddatabase service via user systems 12.

In some implementations, the system 16 implements a web-based customerrelationship management (CRM) system. For example, in some suchimplementations, the system 16 includes application servers configuredto implement and execute CRM software applications as well as providerelated data, code, forms, renderable web pages and documents and otherinformation to and from user systems 12 and to store to, and retrievefrom, a database system related data, objects, and Web page content. Insome MTS implementations, data for multiple tenants may be stored in thesame physical database object in tenant database 22. In some suchimplementations, tenant data is arranged in the storage medium(s) oftenant database 22 so that data of one tenant is kept logically separatefrom that of other tenants so that one tenant does not have access toanother tenant's data, unless such data is expressly shared. The system16 also implements applications other than, or in addition to, a CRMapplication. For example, the system 16 can provide tenant access tomultiple hosted (standard and custom) applications, including a CRMapplication. User (or third party developer) applications, which may ormay not include CRM, may be supported by the application platform 18.The application platform 18 manages the creation and storage of theapplications into one or more database objects and the execution of theapplications in one or more virtual machines in the process space of thesystem 16.

According to some implementations, each system 16 is configured toprovide web pages, forms, applications, data and media content to user(client) systems 12 to support the access by user systems 12 as tenantsof system 16. As such, system 16 provides security mechanisms to keepeach tenant's data separate unless the data is shared. If more than oneMTS is used, they may be located in close proximity to one another (forexample, in a server farm located in a single building or campus), orthey may be distributed at locations remote from one another (forexample, one or more servers located in city A and one or more serverslocated in city B). As used herein, each MTS could include one or morelogically or physically connected servers distributed locally or acrossone or more geographic locations. Additionally, the term “server” ismeant to refer to a computing device or system, including processinghardware and process space(s), an associated storage medium such as amemory device or database, and, in some instances, a databaseapplication (for example, OODBMS or RDBMS) as is well known in the art.It should also be understood that “server system” and “server” are oftenused interchangeably herein. Similarly, the database objects describedherein can be implemented as part of a single database, a distributeddatabase, a collection of distributed databases, a database withredundant online or offline backups or other redundancies, etc., and caninclude a distributed database or storage network and associatedprocessing intelligence.

The network 14 can be or include any network or combination of networksof systems or devices that communicate with one another. For example,the network 14 can be or include any one or any combination of a LAN(local area network), WAN (wide area network), telephone network,wireless network, cellular network, point-to-point network, starnetwork, token ring network, hub network, or other appropriateconfiguration. The network 14 can include a TCP/IP (Transfer ControlProtocol and Internet Protocol) network, such as the global internetworkof networks often referred to as the “Internet” (with a capital “I”).The Internet will be used in many of the examples herein. However, itshould be understood that the networks that the disclosedimplementations can use are not so limited, although TCP/IP is afrequently implemented protocol.

The user systems 12 can communicate with system 16 using TCP/IP and, ata higher network level, other common Internet protocols to communicate,such as HTTP, FTP, AFS, WAP, etc. In an example where HTTP is used, eachuser system 12 can include an HTTP client commonly referred to as a “webbrowser” or simply a “browser” for sending and receiving HTTP signals toand from an HTTP server of the system 16. Such an HTTP server can beimplemented as the sole network interface 20 between the system 16 andthe network 14, but other techniques can be used in addition to orinstead of these techniques. In some implementations, the networkinterface 20 between the system 16 and the network 14 includes loadsharing functionality, such as round-robin HTTP request distributors tobalance loads and distribute incoming HTTP requests evenly over a numberof servers. In MTS implementations, each of the servers can have accessto the MTS data; however, other alternative configurations may be usedinstead.

The user systems 12 can be implemented as any computing device(s) orother data processing apparatus or systems usable by users to access thedatabase system 16. For example, any of user systems 12 can be a desktopcomputer, a work station, a laptop computer, a tablet computer, ahandheld computing device, a mobile cellular phone (for example, a“smartphone”), or any other Wi-Fi-enabled device, wireless accessprotocol (WAP)-enabled device, or other computing device capable ofinterfacing directly or indirectly to the Internet or other network. Theterms “user system” and “computing device” are used interchangeablyherein with one another and with the term “computer.” As describedabove, each user system 12 typically executes an HTTP client, forexample, a web browsing (or simply “browsing”) program, such as a webbrowser based on the WebKit platform, Microsoft's Internet Explorerbrowser, Netscape's Navigator browser, Opera's browser, Mozilla'sFirefox browser, or a WAP-enabled browser in the case of a cellularphone, PDA or other wireless device, or the like, allowing a user (forexample, a subscriber of on-demand services provided by the system 16)of the user system 12 to access, process and view information, pages andapplications available to it from the system 16 over the network 14.

Each user system 12 also typically includes one or more user inputdevices, such as a keyboard, a mouse, a trackball, a touch pad, a touchscreen, a pen or stylus or the like, for interacting with a graphicaluser interface (GUI) provided by the browser on a display (for example,a monitor screen, liquid crystal display (LCD), light-emitting diode(LED) display, among other possibilities) of the user system 12 inconjunction with pages, forms, applications and other informationprovided by the system 16 or other systems or servers. For example, theuser interface device can be used to access data and applications hostedby system 16, and to perform searches on stored data, and otherwiseallow a user to interact with various GUI pages that may be presented toa user. As discussed above, implementations are suitable for use withthe Internet, although other networks can be used instead of or inaddition to the Internet, such as an intranet, an extranet, a virtualprivate network (VPN), a non-TCP/IP based network, any LAN or WAN or thelike.

The users of user systems 12 may differ in their respective capacities,and the capacity of a particular user system 12 can be entirelydetermined by permissions (permission levels) for the current user ofsuch user system. For example, where a salesperson is using a particularuser system 12 to interact with the system 16, that user system can havethe capacities allotted to the salesperson. However, while anadministrator is using that user system 12 to interact with the system16, that user system can have the capacities allotted to thatadministrator. Where a hierarchical role model is used, users at onepermission level can have access to applications, data, and databaseinformation accessible by a lower permission level user, but may nothave access to certain applications, database information, and dataaccessible by a user at a higher permission level. Thus, different usersgenerally will have different capabilities with regard to accessing andmodifying application and database information, depending on the users'respective security or permission levels (also referred to as“authorizations”).

According to some implementations, each user system 12 and some or allof its components are operator-configurable using applications, such asa browser, including computer code executed using a central processingunit (CPU) such as an Intel Pentium® processor or the like. Similarly,the system 16 (and additional instances of an MTS, where more than oneis present) and all of its components can be operator-configurable usingapplication(s) including computer code to run using the processor system17, which may be implemented to include a CPU, which may include anIntel Pentium® processor or the like, or multiple CPUs.

The system 16 includes tangible computer-readable media havingnon-transitory instructions stored thereon/in that are executable by orused to program a server or other computing system (or collection ofsuch servers or computing systems) to perform some of the implementationof processes described herein. For example, computer program code 26 canimplement instructions for operating and configuring the system 16 tointercommunicate and to process web pages, applications and other dataand media content as described herein. In some implementations, thecomputer code 26 can be downloadable and stored on a hard disk, but theentire program code, or portions thereof, also can be stored in anyother volatile or non-volatile memory medium or device as is well known,such as a ROM or RAM, or provided on any media capable of storingprogram code, such as any type of rotating media including floppy disks,optical discs, digital versatile disks (DVD), compact disks (CD),microdrives, and magneto-optical disks, and magnetic or optical cards,nanosystems (including molecular memory ICs), or any other type ofcomputer-readable medium or device suitable for storing instructions ordata. Additionally, the entire program code, or portions thereof, may betransmitted and downloaded from a software source over a transmissionmedium, for example, over the Internet, or from another server, as iswell known, or transmitted over any other existing network connection asis well known (for example, extranet, VPN, LAN, etc.) using anycommunication medium and protocols (for example, TCP/IP, HTTP, HTTPS,Ethernet, etc.) as are well known. It will also be appreciated thatcomputer code for the disclosed implementations can be realized in anyprogramming language that can be executed on a server or other computingsystem such as, for example, C, C++, HTML, any other markup language,Java™, JavaScript, ActiveX, any other scripting language, such asVBScript, and many other programming languages as are well known may beused. (Java™ is a trademark of Sun Microsystems, Inc.).

FIG. 1B shows a block diagram of example implementations of elements ofFIG. 1A and example interconnections between these elements according tosome implementations. That is, FIG. 1B also illustrates environment 10,but FIG. 1B, various elements of the system 16 and variousinterconnections between such elements are shown with more specificityaccording to some more specific implementations. Additionally, in FIG.1B, the user system 12 includes a processor system 12A, a memory system12B, an input system 12C, and an output system 12D. The processor system12A can include any suitable combination of one or more processors. Thememory system 12B can include any suitable combination of one or morememory devices. The input system 12C can include any suitablecombination of input devices, such as one or more touchscreeninterfaces, keyboards, mice, trackballs, scanners, cameras, orinterfaces to networks. The output system 12D can include any suitablecombination of output devices, such as one or more display devices,printers, or interfaces to networks.

In FIG. 1B, the network interface 20 is implemented as a set of HTTPapplication servers 100 ₁-100 _(N). Each application server 100, alsoreferred to herein as an “app server”, is configured to communicate withtenant database 22 and the tenant data 23 therein, as well as systemdatabase 24 and the system data 25 therein, to serve requests receivedfrom the user systems 12. The tenant data 23 can be divided intoindividual tenant storage spaces 112, which can be physically orlogically arranged or divided. Within each tenant storage space 112,user storage 114 and application metadata 116 can similarly be allocatedfor each user. For example, a copy of a user's most recently used (MRU)items can be stored to user storage 114. Similarly, a copy of MRU itemsfor an entire organization that is a tenant can be stored to tenantstorage space 112.

The process space 28 includes system process space 102, individualtenant process spaces 104 and a tenant management process space 110. Theapplication platform 18 includes an application setup mechanism 38 thatsupports application developers' creation and management ofapplications. Such applications and others can be saved as metadata intotenant database 22 by save routines 36 for execution by subscribers asone or more tenant process spaces 104 managed by tenant managementprocess 110, for example. Invocations to such applications can be codedusing PL/SOQL 34, which provides a programming language style interfaceextension to API 32. A detailed description of some PL/SOQL languageimplementations is discussed in commonly assigned U.S. Pat. No.7,730,478, titled METHOD AND SYSTEM FOR ALLOWING ACCESS TO DEVELOPEDAPPLICATIONS VIA A MULTI-TENANT ON-DEMAND DATABASE SERVICE, by CraigWeissman, issued on Jun. 1, 2010, and hereby incorporated by referencein its entirety and for all purposes. Invocations to applications can bedetected by one or more system processes, which manage retrievingapplication metadata 116 for the subscriber making the invocation andexecuting the metadata as an application in a virtual machine.

The system 16 of FIG. 1B also includes a user interface (UI) 30 and anapplication programming interface (API) 32 to system 16 residentprocesses to users or developers at user systems 12. In some otherimplementations, the environment 10 may not have the same elements asthose listed above or may have other elements instead of, or in additionto, those listed above.

Each application server 100 can be communicably coupled with tenantdatabase 22 and system database 24, for example, having access to tenantdata 23 and system data 25, respectively, via a different networkconnection. For example, one application server 100 ₁ can be coupled viathe network 14 (for example, the Internet), another application server100 _(N-1) can be coupled via a direct network link, and anotherapplication server 100 _(N) can be coupled by yet a different networkconnection. Transfer Control Protocol and Internet Protocol (TCP/IP) areexamples of typical protocols that can be used for communicating betweenapplication servers 100 and the system 16. However, it will be apparentto one skilled in the art that other transport protocols can be used tooptimize the system 16 depending on the network interconnections used.

In some implementations, each application server 100 is configured tohandle requests for any user associated with any organization that is atenant of the system 16. Because it can be desirable to be able to addand remove application servers 100 from the server pool at any time andfor various reasons, in some implementations there is no server affinityfor a user or organization to a specific application server 100. In somesuch implementations, an interface system implementing a load balancingfunction (for example, an F5 Big-IP load balancer) is communicablycoupled between the application servers 100 and the user systems 12 todistribute requests to the application servers 100. In oneimplementation, the load balancer uses a least-connections algorithm toroute user requests to the application servers 100. Other examples ofload balancing algorithms, such as round robin andobserved-response-time, also can be used. For example, in someinstances, three consecutive requests from the same user could hit threedifferent application servers 100, and three requests from differentusers could hit the same application server 100. In this manner, by wayof example, system 16 can be a multi-tenant system in which system 16handles storage of, and access to, different objects, data andapplications across disparate users and organizations.

In one example storage use case, one tenant can be a company thatemploys a sales force where each salesperson uses system 16 to manageaspects of their sales. A user can maintain contact data, leads data,customer follow-up data, performance data, goals and progress data,etc., all applicable to that user's personal sales process (for example,in tenant database 22). In an example of a MTS arrangement, because allof the data and the applications to access, view, modify, report,transmit, calculate, etc., can be maintained and accessed by a usersystem 12 having little more than network access, the user can managehis or her sales efforts and cycles from any of many different usersystems. For example, when a salesperson is visiting a customer and thecustomer has Internet access in their lobby, the salesperson can obtaincritical updates regarding that customer while waiting for the customerto arrive in the lobby.

While each user's data can be stored separately from other users' dataregardless of the employers of each user, some data can beorganization-wide data shared or accessible by several users or all ofthe users for a given organization that is a tenant. Thus, there can besome data structures managed by system 16 that are allocated at thetenant level while other data structures can be managed at the userlevel. Because an MTS can support multiple tenants including possiblecompetitors, the MTS can have security protocols that keep data,applications, and application use separate. Also, because many tenantsmay opt for access to an MTS rather than maintain their own system,redundancy, up-time, and backup are additional functions that can beimplemented in the MTS. In addition to user-specific data andtenant-specific data, the system 16 also can maintain system level datausable by multiple tenants or other data. Such system level data caninclude industry reports, news, postings, and the like that are sharableamong tenants.

In some implementations, the user systems 12 (which also can be clientsystems) communicate with the application servers 100 to request andupdate system-level and tenant-level data from the system 16. Suchrequests and updates can involve sending one or more queries to tenantdatabase 22 or system database 24. The system 16 (for example, anapplication server 100 in the system 16) can automatically generate oneor more Structured Query Language (SQL) statements (for example, one ormore SQL queries) designed to access the desired information. Systemdatabase 24 can generate query plans to access the requested data fromthe database. The term “query plan” generally refers to one or moreoperations used to access information in a database system.

Each database can generally be viewed as a collection of objects, suchas a set of logical tables, containing data fitted into predefined orcustomizable categories. A “table” is one representation of a dataobject, and may be used herein to simplify the conceptual description ofobjects and custom objects according to some implementations. It shouldbe understood that “table” and “object” may be used interchangeablyherein. Each table generally contains one or more data categorieslogically arranged as columns or fields in a viewable schema. Each rowor element of a table can contain an instance of data for each categorydefined by the fields. For example, a CRM database can include a tablethat describes a customer with fields for basic contact information suchas name, address, phone number, fax number, etc. Another table candescribe a purchase order, including fields for information such ascustomer, product, sale price, date, etc. In some MTS implementations,standard entity tables can be provided for use by all tenants. For CRMdatabase applications, such standard entities can include tables forcase, account, contact, lead, and opportunity data objects, eachcontaining pre-defined fields. As used herein, the term “entity” alsomay be used interchangeably with “object” and “table.”

In some MTS implementations, tenants are allowed to create and storecustom objects, or may be allowed to customize standard entities orobjects, for example by creating custom fields for standard objects,including custom index fields. Commonly assigned U.S. Pat. No.7,779,039, titled CUSTOM ENTITIES AND FIELDS IN A MULTI-TENANT DATABASESYSTEM, by Weissman et al., issued on Aug. 17, 2010, and herebyincorporated by reference in its entirety and for all purposes, teachessystems and methods for creating custom objects as well as customizingstandard objects in a multi-tenant database system. In someimplementations, for example, all custom entity data rows are stored ina single multi-tenant physical table, which may contain multiple logicaltables per organization. It is transparent to customers that theirmultiple “tables” are in fact stored in one large table or that theirdata may be stored in the same table as the data of other customers.

FIG. 2A shows a system diagram illustrating example architecturalcomponents of an on-demand database service environment 200 according tosome implementations. A client machine communicably connected with thecloud 204, generally referring to one or more networks in combination,as described herein, can communicate with the on-demand database serviceenvironment 200 via one or more edge routers 208 and 212. A clientmachine can be any of the examples of user systems 12 described above.The edge routers can communicate with one or more core switches 220 and224 through a firewall 216. The core switches can communicate with aload balancer 228, which can distribute server load over different pods,such as the pods 240 and 244. The pods 240 and 244, which can eachinclude one or more servers or other computing resources, can performdata processing and other operations used to provide on-demand services.Communication with the pods can be conducted via pod switches 232 and236. Components of the on-demand database service environment cancommunicate with database storage 256 through a database firewall 248and a database switch 252.

As shown in FIGS. 2A and 2B, accessing an on-demand database serviceenvironment can involve communications transmitted among a variety ofdifferent hardware or software components. Further, the on-demanddatabase service environment 200 is a simplified representation of anactual on-demand database service environment. For example, while onlyone or two devices of each type are shown in FIGS. 2A and 2B, someimplementations of an on-demand database service environment can includeanywhere from one to several devices of each type. Also, the on-demanddatabase service environment need not include each device shown in FIGS.2A and 2B, or can include additional devices not shown in FIGS. 2A and2B.

Additionally, it should be appreciated that one or more of the devicesin the on-demand database service environment 200 can be implemented onthe same physical device or on different hardware. Some devices can beimplemented using hardware or a combination of hardware and software.Thus, terms such as “data processing apparatus,” “machine,” “server” and“device” as used herein are not limited to a single hardware device,rather references to these terms can include any suitable combination ofhardware and software configured to provide the described functionality.

The cloud 204 is intended to refer to a data network or multiple datanetworks, often including the Internet. Client machines communicablyconnected with the cloud 204 can communicate with other components ofthe on-demand database service environment 200 to access servicesprovided by the on-demand database service environment. For example,client machines can access the on-demand database service environment toretrieve, store, edit, or process information. In some implementations,the edge routers 208 and 212 route packets between the cloud 204 andother components of the on-demand database service environment 200. Forexample, the edge routers 208 and 212 can employ the Border GatewayProtocol (BGP). The BGP is the core routing protocol of the Internet.The edge routers 208 and 212 can maintain a table of IP networks or‘prefixes’, which designate network reachability among autonomoussystems on the Internet.

In some implementations, the firewall 216 can protect the innercomponents of the on-demand database service environment 200 fromInternet traffic. The firewall 216 can block, permit, or deny access tothe inner components of the on-demand database service environment 200based upon a set of rules and other criteria. The firewall 216 can actas one or more of a packet filter, an application gateway, a statefulfilter, a proxy server, or any other type of firewall.

In some implementations, the core switches 220 and 224 are high-capacityswitches that transfer packets within the on-demand database serviceenvironment 200. The core switches 220 and 224 can be configured asnetwork bridges that quickly route data between different componentswithin the on-demand database service environment. In someimplementations, the use of two or more core switches 220 and 224 canprovide redundancy or reduced latency.

In some implementations, the pods 240 and 244 perform the core dataprocessing and service functions provided by the on-demand databaseservice environment. Each pod can include various types of hardware orsoftware computing resources. An example of the pod architecture isdiscussed in greater detail with reference to FIG. 2B. In someimplementations, communication between the pods 240 and 244 is conductedvia the pod switches 232 and 236. The pod switches 232 and 236 canfacilitate communication between the pods 240 and 244 and clientmachines communicably connected with the cloud 204, for example via coreswitches 220 and 224. Also, the pod switches 232 and 236 may facilitatecommunication between the pods 240 and 244 and the database storage 256.In some implementations, the load balancer 228 can distribute workloadbetween the pods 240 and 244. Balancing the on-demand service requestsbetween the pods can assist in improving the use of resources,increasing throughput, reducing response times, or reducing overhead.The load balancer 228 may include multilayer switches to analyze andforward traffic.

In some implementations, access to the database storage 256 is guardedby a database firewall 248. The database firewall 248 can act as acomputer application firewall operating at the database applicationlayer of a protocol stack. The database firewall 248 can protect thedatabase storage 256 from application attacks such as structure querylanguage (SQL) injection, database rootkits, and unauthorizedinformation disclosure. In some implementations, the database firewall248 includes a host using one or more forms of reverse proxy services toproxy traffic before passing it to a gateway router. The databasefirewall 248 can inspect the contents of database traffic and blockcertain content or database requests. The database firewall 248 can workon the SQL application level atop the TCP/IP stack, managingapplications' connection to the database or SQL management interfaces aswell as intercepting and enforcing packets traveling to or from adatabase network or application interface.

In some implementations, communication with the database storage 256 isconducted via the database switch 252. The multi-tenant database storage256 can include more than one hardware or software components forhandling database queries. Accordingly, the database switch 252 candirect database queries transmitted by other components of the on-demanddatabase service environment (for example, the pods 240 and 244) to thecorrect components within the database storage 256. In someimplementations, the database storage 256 is an on-demand databasesystem shared by many different organizations as described above withreference to FIGS. 1A and 1B.

FIG. 2B shows a system diagram further illustrating examplearchitectural components of an on-demand database service environmentaccording to some implementations. The pod 244 can be used to renderservices to a user of the on-demand database service environment 200. Insome implementations, each pod includes a variety of servers or othersystems. The pod 244 includes one or more content batch servers 264,content search servers 268, query servers 282, file force servers 286,access control system (ACS) servers 280, batch servers 284, and appservers 288. The pod 244 also can include database instances 290, quickfile systems (QFS) 292, and indexers 294. In some implementations, someor all communication between the servers in the pod 244 can betransmitted via the switch 236.

In some implementations, the app servers 288 include a hardware orsoftware framework dedicated to the execution of procedures (forexample, programs, routines, scripts) for supporting the construction ofapplications provided by the on-demand database service environment 200via the pod 244. In some implementations, the hardware or softwareframework of an app server 288 is configured to execute operations ofthe services described herein, including performance of the blocks ofvarious methods or processes described herein. In some alternativeimplementations, two or more app servers 288 can be included andcooperate to perform such methods, or one or more other serversdescribed herein can be configured to perform the disclosed methods.

The content batch servers 264 can handle requests internal to the pod.Some such requests can be long-running or not tied to a particularcustomer. For example, the content batch servers 264 can handle requestsrelated to log mining, cleanup work, and maintenance tasks. The contentsearch servers 268 can provide query and indexer functions. For example,the functions provided by the content search servers 268 can allow usersto search through content stored in the on-demand database serviceenvironment. The file force servers 286 can manage requests forinformation stored in the Fileforce storage 298. The Fileforce storage298 can store information such as documents, images, and basic largeobjects (BLOBs). By managing requests for information using the fileforce servers 286, the image footprint on the database can be reduced.The query servers 282 can be used to retrieve information from one ormore file systems. For example, the query system 282 can receiverequests for information from the app servers 288 and transmitinformation queries to the NFS 296 located outside the pod.

The pod 244 can share a database instance 290 configured as amulti-tenant environment in which different organizations share accessto the same database. Additionally, services rendered by the pod 244 maycall upon various hardware or software resources. In someimplementations, the ACS servers 280 control access to data, hardwareresources, or software resources. In some implementations, the batchservers 284 process batch jobs, which are used to run tasks at specifiedtimes. For example, the batch servers 284 can transmit instructions toother servers, such as the app servers 288, to trigger the batch jobs.

In some implementations, the QFS 292 is an open source file systemavailable from Sun Microsystems® of Santa Clara, Calif. The QFS canserve as a rapid-access file system for storing and accessinginformation available within the pod 244. The QFS 292 can support somevolume management capabilities, allowing many disks to be groupedtogether into a file system. File system metadata can be kept on aseparate set of disks, which can be useful for streaming applicationswhere long disk seeks cannot be tolerated. Thus, the QFS system cancommunicate with one or more content search servers 268 or indexers 294to identify, retrieve, move, or update data stored in the network filesystems 296 or other storage systems.

In some implementations, one or more query servers 282 communicate withthe NFS 296 to retrieve or update information stored outside of the pod244. The NFS 296 can allow servers located in the pod 244 to accessinformation to access files over a network in a manner similar to howlocal storage is accessed. In some implementations, queries from thequery servers 282 are transmitted to the NFS 296 via the load balancer228, which can distribute resource requests over various resourcesavailable in the on-demand database service environment. The NFS 296also can communicate with the QFS 292 to update the information storedon the NFS 296 or to provide information to the QFS 292 for use byservers located within the pod 244.

In some implementations, the pod includes one or more database instances290. The database instance 290 can transmit information to the QFS 292.When information is transmitted to the QFS, it can be available for useby servers within the pod 244 without using an additional database call.In some implementations, database information is transmitted to theindexer 294. Indexer 294 can provide an index of information availablein the database 290 or QFS 292. The index information can be provided tofile force servers 286 or the QFS 292.

II. Extracting and Processing Metrics from System Generated Events

Data taken from logged interactions of users with a multi-tenantinformation system may be raw event data. The raw event data may includedata collected by logged interactions of any number of event types. Oneexample of an event type is a login event, which occurs every time auser logs into an application of the multi-tenant information system. Alogin might produce raw event data indicating an Application ProgramInterface (API) type and version if an API is used for the login, abrowser and client version if a User Interface (UI) is used for thelogin, a time of the login, a platform used for the login, an IP addressfrom which the login took place, an identity of the user, whether thelogin was successful or not, or the like, or combinations thereof.

The amount of raw event data captured from just the login event type fora single user of a single tenant may be significant. For instance, asingle user of a single tenant may login say 10 times in an hour,multiple times a week. This is one user of one tenant—there may be amultitude of other users of the same tenant plus a multitude of otheruser of another tenant all creating login events. And login events maybe only one of more than one event type captured by the logging system.Manually querying the raw event data or a login event object, by atenant (or for the tenant), may consume processing cycles of one or moremachines involved with the query, possibly overwhelming computingresources or making those resources partially unavailable for otherparallel tasks.

In an example, a group by function is applied at an interval to a loginevent object to create a platform event metrics object, i.e. to roll upall of the grouped events for the interval. The group by function may beapplied to all raw event data available at the interval, or only to theraw event data collected since the previous occurrence of the interval.The platform event metrics object may be exposed to a tenant. The tenantmay query the platform event metric object, which may consume lessprocessing cycles than querying the login event object.

FIG. 3 is an operational flow diagram illustrating a process that may beperformed by a processing system of a database system for extracting andprocessing metrics from system generated events.

In block 301, the processing system categorizes data taken from loggedinteractions of users with a multi-tenant information system to providea metric. The metric may be used to group events of the raw event data.

In an example, the metric may be based on number of logins, number oflogins for a particular user, number of logins from a particularbrowser, number of logins in a specified timeframe, login duration,login IP address, login browser type, or the like, or combinationsthereof. In an example, the processing system may be configured to allowa metric to be predefined in a declarative way with reference tocomponents or attributes. In an example, components of a metric includea metric time, e.g. an interval, and a name-value pair.

FIG. 4A shows an example of metric definition. The example eXtensibleMarkup Language (XML) code defines a metric “Number of DistinctApplications By User”. The XML code defines a Metric Name 401 (alsoreferred to as Metric Type), as well as other attributes of the metric,e.g. in this case function, function input field, event name, andaggregation field.

Referring again to FIG. 3, in block 302 the processing system mayassociate a plurality of attributes with the metric. In one example, allof the attributes are associated with the metric in order to predefinethe metric before, i.e. not responsively, to receiving a query from atenant. The attributes may include timeframe, source object, databasetable, target field, or the like, or combinations thereof.

FIG. 4B is an example of raw event data. FIG. 4B shows an example of aSalesforce Object Query Language (SOQL) query 401 of the login eventobject selecting an application attribute equal to “CloudLock ComplianceFor Salesforce”. The login event in FIG. 4B represents raw log datawhere each reference to the CloudLock Compliance for Salesforcerepresents an individual login. This raw event data may be rolled upinto a variety of aggregates or metrics as illustrated in FIG. 4C.

Referring again to FIG. 3, in block 303 the processing systemperiodically calculates the metric for a particular one of the tenantsaccording to the associated attributes. In one example, the metric maybe calculated every hour. In one example, a query by a tenant may beperformed on a result of one of the periodic calculations, e.g. on themost recent periodic calculation results. In other words, the result maybe pre-calculated without beforehand knowledge that a query will bereceived.

FIG. 4C shows an example of an SOQL query of the platform event metricobject. The query results 421 apply an attribute for a particular userto the result of pre-calculating the metric at the interval. Rows of thetable of query results 421 corresponds to events, and columns correspondto fields. Each field may correspond to one of the attributes of themetric.

FIG. 4C shows an example of performing a SOQL query over rolled-upaggregate information taken from the raw event data. That informationmay be rolled-up based on any number of attributes or fields from theraw event data. For instance, the ability to determine how many distinctapplications were used in the past hour versus the total number of timesa particular user logged in. Here, the query results 421 show that forthe time interval, e.g. one hour, a metric value for the metric numberof distinct applications by user is equal to one. The metric value forthis time interval can be combined with metric values from other timeintervals to determine a trend over time for the metric number ofdistinct applications by user. If a different metric was checked for thesame raw data, e.g. the metric number of logins by user, a metric valuemay have a different count, say four, despite the fact that a user mayhave only logged into one application, e.g. CloudLock for Compliance.

The tool illustrated in FIG. 4C allows a tenant to select a metric or acombination of metrics, optionally select any number of attributes, andreceive a result responsive to the selection (the result may be used forforensic analysis, for example). The result may be a list of relevantdata from relevant logged events, or the result may be an image from avisualization tool. FIG. 4D shows an example of the query results 421mapped to a visualization tool.

In an example, the processing system may be configured to, responsive toreceiving a query selecting an attribute value from a particular one ofthe tenants, applying the attribute value to a result of apre-calculation of the metric for the particular one of the tenants. Thepre-calculation may be performed prior to receiving the query withoutbeforehand knowledge of the query. The processing system may provide, tothe particular one of the tenants, a result of the application of theattribute value to the result of the pre-calculation of the metric forthe particular one of the tenants.

In an example, the processing system may be configured to generate aprofile for a user indicated by event data taken from logged userinteractions with a multi-tenant information system. The profile may bebased on a result of periodic calculations of the metric. The processingsystem may electronically store the generated profile in a data store.The processing system may compare information taken from a most recentlylogged interaction to the generated profile. The processing system maydetermine whether to transmit an alert response to a result of thecomparison.

In an example, the categorization by the processing system may includeselecting an event type, such as login event. The processing system maybe configured to filter events of the event data according to theselected event type.

In an example, the processing system may be configured to identify anaverage number of logins for a duration using a result of one of theperiodic calculations, e.g. according to a most recent one of the periodcalculations. The processing system may be configured to identify athreshold according to the average. The processing system may beconfigured to count a number of logins during a time periodcorresponding to the duration. The processing system may be configuredto determine whether the count is greater than the determined threshold,and transmit an alert responsive to the determination.

In an example, the processing system may be configured to identify afirst trend for a time of day logged in for a group of users of thetenant. The processing system may be configured to identify a secondtrend for a time of day logged in for a user of the group of users. Theprocessing system may be configured to determine whether to transmit analert using the first and second trends.

In an example, the processing system may be configured to detect achange in IP address between successive logins for a user. Theprocessing system may be configured to determine whether a firstduration between logins associated with the detected change is less thana second duration, and transmit an alert response to the determination.

In an example, the processing system may be configured to detect achange in browser type or browser version between successive logins fora user, determining whether to transmit an alert according to thedetected change.

In an example, the processing system may be configured to provide adeclarative ability to define system generated events that can berolled-up into an aggregated metric, which may ensure that it is easy toboth create and maintain metrics over time by declaring a series ofattributes about the metric. In an example, the attributes includemetric name, source object or database table, aggregate function, targetfield, aggregation clause, interval, timeframe, or the like, orcombinations thereof. In an example, a series of system generatedmetrics may be defined declaratively based on common and repeatablecharacteristics.

Co-pending U.S. patent application Ser. No. 14/688,917 entitledEXTRACTION AND CAPTURE OF INFORMATION FROM CUSTOMIZABLE HEADER describesfeatures for collecting data, which in an example may includeunstructured data. In an example, any of the processes/operationsdescribed herein may be combined with any of the processes/operationsdescribed in the co-pending application. For instance, in an example, aprocessing system periodically calculates a metric based on structureddata, e.g. event data, and unstructured data collected using featuresdescribed in the co-pending application. A query may be received from aparticular one of the tenants, the query applying a selected attributevalue to a result of a pre-calculation of the metric based on thestructured and unstructured data. The pre-calculation may be performedprior to receiving the query without beforehand knowledge of the query.The processing system may provide a result of the application of theattribute value to the particular tenant.

The system and apparatus described above may use dedicated processorsystems, micro controllers, programmable logic devices, microprocessors,or any combination thereof, to perform some or all of the operationsdescribed herein. Some of the operations described above may beimplemented in software and other operations may be implemented inhardware. Any of the operations, processes, and/or methods describedherein may be performed by an apparatus, a device, and/or a systemsubstantially similar to those as described herein and with reference tothe illustrated figures.

The processing system may execute instructions or “code” stored inmemory. The memory may store data as well. The processing system mayinclude, but may not be limited to, an analog processor, a digitalprocessor, a microprocessor, a multi-core processor, a processor array,a network processor, or the like. The processing system may be part ofan integrated control system or system manager, or may be provided as aportable electronic device configured to interface with a networkedsystem either locally or remotely via wireless transmission.

The processor memory may be integrated together with the processingsystem, for example RAM or FLASH memory disposed within an integratedcircuit microprocessor or the like. In other examples, the memory maycomprise an independent device, such as an external disk drive, astorage array, a portable FLASH key fob, or the like. The memory andprocessing system may be operatively coupled together, or incommunication with each other, for example by an I/O port, a networkconnection, or the like, and the processing system may read a filestored on the memory. Associated memory may be “read only” by design(ROM) by virtue of permission settings, or not. Other examples of memorymay include, but may not be limited to, WORM, EPROM, EEPROM, FLASH, orthe like, which may be implemented in solid state semiconductor devices.Other memories may comprise moving parts, such as a known rotating diskdrive. All such memories may be “machine-readable” and may be readableby a processing system.

Operating instructions or commands may be implemented or embodied intangible forms of stored computer software (also known as “computerprogram” or “code”). Programs, or code, may be stored in a digitalmemory and may be read by the processing system. “Computer-readablestorage medium” (or alternatively, “machine-readable storage medium”)may include all of the foregoing types of memory, as well as newtechnologies of the future, as long as the memory may be capable ofstoring digital information in the nature of a computer program or otherdata, at least temporarily, and as long as the stored information may be“read” by an appropriate processing system. The term “computer-readable”may not be limited to the historical usage of “computer” to imply acomplete mainframe, mini-computer, desktop or even laptop computer.Rather, “computer-readable” may comprise storage medium that may bereadable by a processor, a processing system, or any computing system.Such media may be any available media that may be locally and/orremotely accessible by a computer or a processor, and may includevolatile and non-volatile media, and removable and non-removable media,or any combination thereof.

A program stored in a computer-readable storage medium may comprise acomputer program product. For example, a storage medium may be used as aconvenient means to store or transport a computer program. For the sakeof convenience, the operations may be described as variousinterconnected or coupled functional blocks or diagrams. However, theremay be cases where these functional blocks or diagrams may beequivalently aggregated into a single logic device, program or operationwith unclear boundaries.

While one or more implementations have been described by way of exampleand in terms of the specific embodiments, it is to be understood thatone or more implementations are not limited to the disclosedembodiments. To the contrary, it is intended to cover variousmodifications and similar arrangements as would be apparent to thoseskilled in the art. Therefore, the scope of the appended claims shouldbe accorded the broadest interpretation so as to encompass all suchmodifications and similar arrangements.

1. A database system, comprising: a processing system; and a memorydevice coupled to the processing system, the memory device havinginstructions stored thereon that, in response to execution by theprocessing system, cause the processing system to perform operationscomprising: categorizing event data taken from logged interactions ofusers with a multi-tenant information system to provide a metric;associating a plurality of attributes with the metric, wherein theplurality of attributes include interval and at least one of aggregationfunction, aggregation clause, or aggregation filter; periodicallycalculating the metric for a particular one of the tenants according tothe associated attributes; and electronically storing the periodicallycalculated metrics.
 2. The database system of claim 1, wherein theoperations further comprising: responsive to receiving a query from theparticular one of the tenants, the query selecting an attribute value,applying the selected attribute value to a result of a pre-calculationof the metric for the particular one of the tenants; wherein thepre-calculation is performed prior to receiving the query withoutbeforehand knowledge of the query; and providing, to the particular oneof the tenants, a result of the application of the attribute value. 3.The database system of claim 1, wherein the operations further comprise:generating a profile for one of the users based on the periodiccalculations; and electronically storing the generated profile.
 4. Thedatabase system of claim 3, wherein the operations further comprise:comparing information taken from a most recent logged interaction to thegenerated profile; and determining whether to transmit an alertresponsive to a result of the comparison.
 5. The database system ofclaim 1, wherein the categorization comprises: selecting an event type;and filtering events of the event data according to the selected eventtype.
 6. The database system of claim 5, wherein the event typecomprises login event.
 7. The database system of claim 1, wherein themetric corresponds to at least one event attribute including at leastone of number of logins, login duration, login IP address, or loginbrowser type.
 8. The database system of claim 7, wherein the operationsfurther comprise: identifying an average number of logins for a durationusing a most recent one of the periodic calculations; identifying athreshold according to the average; counting a number of logins during atime period corresponding to the duration using a most recent one of theperiodic calculations; determining whether the count is greater than thedetermined threshold; and transmitting an alert responsive to thedetermination.
 9. The database system of claim 7, wherein the operationsfurther comprise: identifying a first trend for a time of day logged infor a group of users of the tenant; identifying a second trend for atime of day logged in for a user of the group of users; and determiningwhether to transmit an alert using the first and second trends.
 10. Thedatabase system of claim 7, wherein the operations further comprise:detecting a change in IP address between successive logins for a user;determining whether a first duration between logins associated with thedetected change is less than a second duration; and transmitting analert response to the determination.
 11. The database system of claim 7,wherein the operations further comprise: detecting a change in browsertype or browser version between successive logins for a user; anddetermining whether to transmit an alert according to the detectedchange.
 12. The database system of claim 1, wherein the plurality ofattributes include at least one of timeframe, source object, databasetable, or target field.
 13. A method, comprising: in a first phase:categorizing event data taken from logged interactions of users with amulti-tenant information system to provide a metric; associating aplurality of attributes with the metric, wherein the plurality ofattributes include interval and at least one of aggregation function,aggregation clause, or aggregation filter; periodically calculating,using a processing system of a database system, the metric for aparticular one of the tenants according to the associated attributes;electronically storing the periodically calculated metrics; and in asecond phase that is after the first phase, the second phase initiatedby receipt of a query from the particular one of the tenants; applying,using the processing system of the database system, a selected attributevalue of the received query to one of the stored metrics; and providinga result of the application of the selected attribute value of thereceived query to the one of the stored metrics.
 14. The method of claim13, further comprising: generating a profile for one of the users basedon the periodic calculations; and electronically storing the generatedprofile.
 15. The method of claim 14, further comprising: comparinginformation taken from a most recent logged interaction to the generatedprofile; and determining whether to transmit an alert responsive to aresult of the comparison.
 16. The method of claim 13, wherein thecategorization comprises: selecting an event type; and filtering eventsof the event data according to the selected event type.
 17. The methodof claim 16, wherein the event type comprises login event.
 18. Themethod of claim 13, wherein the metric corresponds to at least one eventattribute including at least one of number of logins, login duration,login IP address, or login browser type.
 19. The method of claim 18,further comprising: identifying an average number of logins for aduration using a most recent one of the periodic calculations;identifying a threshold according to the average; counting a number oflogins during a time period corresponding to the duration using a mostrecent one of the periodic calculations; determining whether the countis greater than the determined threshold; and transmitting an alertresponsive to the determination.
 20. The method of claim 18, furthercomprising: identifying a first trend for a time of day logged in for agroup of users of the tenant; identifying a second trend for a time ofday logged in for a user of the group of users; and determining whetherto transmit an alert using the first and second trends.